1. Field of the Invention
The present invention relates to the field of data processing. More specifically, embodiments of the present invention relate to a Java class loading system and method.
2. Related Art
Electronic systems and circuits have made a significant contribution towards the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous electronic technologies such as digital computers, calculators, audio devices, video equipment, and telephone systems have facilitated increased productivity and reduced costs in analyzing and communicating data in most areas of business, science, education and entertainment. These advantageous results are often realized by computer systems implementing a virtual machine such as a Java virtual machine (JVM). A Java virtual machine is a process that runs on a host system executing binaries associated with class files. The JVM implements an abstraction referred to as a class loader that locates bytes associated with a class name and produces a translated representation of a Java class instance in a memory. However, traditional Java virtual machine class loading architectures can be relatively complex and involve a number of restrictive implementation requirements that often result in limited implementation flexibility and typically consume significant system resources.
Java programs typically include classes (e.g., “java.lang.String”) and other data referred to as “resources”. Classes and resources are usually loaded into a Java Virtual Machine (JVM) by a class loader. Each class loader (“loader”) contains one or more “code-sources” (e.g., class/resource archives such as “.jar” or “.zip” files) from which to obtain class files to convert into class instances or resource data for application use. Class and resource names are typically prefixed by a “package” name, such as “java.lang” for the “String” class. Generally, many classes share a package name.
Java is an object oriented language in which classes are “specifications” (expressed as a piece of program code) that define common parameters or properties of objects included in the class. Some environments (e.g., Java two enterprise environments (J2EE)) typically permit concurrent execution of separate applications, where each application can involve multiple modules with Java classes packaged in various forms. The traditional rules governing isolation between these various components generally require the use of multiple “class loaders”, each of which can hold only a single version of any given class. The classes that form a given version of a technology solution (e.g. an XML parser, such as Xerces) are generally packaged and distributed in one or more “code-source” root locations from which the classloader searches for classes. Code sources are generally anything that can be asked for a class or resource data and return it. For example, code sources can be defined to represent physical storage of binary class files, java sources that are compiled, or classes generated on the fly. A class loader in Java normally contains one or more “code-sources” (e.g., “Jar” or “zip” files) from which to load classes. A class loader uses each code source, along with a fully qualified class name (e.g., which includes a class package name) to define a location to search for classes.
Class loaders are typically arranged in a “tree” structure, with each loader having a single parent. When a class load event occurs, a loader is selected (called the “initiating” loader), and the standard search algorithm searches up the parent chain before searching the current (“initiating”) loader. The first class matching the class name is returned. When a “child” contains the same class as one of its parents, the parent's version is traditionally selected effectively “masking” the child's copy. This searching hierarchy often takes a significant amount of time to traverse the different code sources that may contain the appropriate class. There are a number of applications in which time is important and delays can have a significant impact on user experience with the system. For example, conventional startups of a server can take a significant amount of time in which a user has to wait for the system to complete initialization activities before the user can begin actual application processing.
Traditional systems also typically defer searching for a class until the class is first required for method execution. Classes often have dependencies on other classes and a virtual machine may resolve those dependencies during the loading of the dependent class, or again may further defer resolution until the dependency is first required. In either case, an additional class loading search is performed to find the class location. Deferred class loading until first use can be highly recursive with a significant number of code pathways that are either non-debug or native which can complicate diagnosis of common class loading failures resulting from configuration errors.
Complex environments that contain multiple class loaders can significantly complicate loading operations and increase the probability of inopportune time delays. For example, in a J2EE (Java 2 enterprise edition) it is often common for initiating loader to have many ancestors, each containing many code sources. Traversing many code sources to locate the class and the act of loading a class for the first time can consume significant processing time.